1. Field of the Invention
The present invention relates to the field of pooled database server systems. More specifically, the present invention provides a method for providing connections for application processes to a database server.
2. Description of the Related Art
Pooled database server systems often utilize three tier architectures. In three tier architectures, many hundreds of clients can make requests to a limited number of application servers which distribute database access across many database connections to one central database host. Application server designs where processes are multi-threaded in nature have an inherent ability to share database connections between the processing entities by means of intra-process database connection pooling, also referred to as intra-process (threaded) pooled database connections.
To handle many multiples of data-processing requests, most application servers operate according to a multiprocessing model. Two basic multiprocessing paradigms exist: parallel processing shares all resources (multi-threaded), or parallel processing shares no resources (multi-process). In a multi-threaded configuration, all parallel threads operate within one address space; thus all resources are available to all threads. In a multi-process configuration, each parallel process runs in a separate isolated address space; thus resource sharing requires an active exchange mechanism.
The state-of-the-art implantation of sharing (pooling) database connections amongst threads is therefore trivial; as the sharing occurs within one process. This invention describes a mechanism of sharing database connections in the non-trivial multiple process model.
In the multiple process model, pooled database connections can also be shared amongst different applications running on the same host, whereas state-of-the-art pooled database connections are only shareable within one application, namely the application running in the process.
The problem is that each database connection potentially causes heavy strain on the database server because resources required per connection are large. When the workload distribution design of the application server is application process oriented rather than thread oriented, it becomes difficult to share the database connections among the processing entities.
In the past, several attempts have been made to solve this problem. U.S. Pat. No. 6,105,067 describes a connection pool management for backend servers using a common interface. The system comprises an application server, one or more backend data servers, a connection pool, and a number of sub-processes for performing steps of the connection pool management. This reduces the overhead required for accessing the data servers.
Another solution to the problem is disclosed on “http://www.dcl.mathcs.emory.edu/downloads/h2o/doc/api/edu/emory/mathcs/util/net/ConnectionPool.html”. Therein is described an implementation of a connection pool class that manages a pool of socket connections to a single network endpoint within a single process. The connection pool creates new connections if none is available and until a pool size limit is reached. The endpoint is represented by a host name and a port number. A client requests connections, uses them, then returns them to the pool. Upon a request for connection, the pool first tries to return a pre-existing idle one, creating a new connection only if none is available. Request may block if pool size limit is reached and all connections are in use. After being returned to the pool, if connection idles for longer than its expiration timeout, it is closed. The connection pool resides in the same address and process space as the application. Application code explicitly interacts with the connection pool by calling specific interfaces provided by the connection pool.
Lastly, U.S. Pat. No. 6,839,732 describes the use of domain socket pairs in communication for tightly coupled transactions. A gateway provides this communication to a server hosting a database management system. Logical agents represent the application connection and are managed by a logical agent scheduler and are passed within the gateway using domain socket pairs.
Most of these state of the art documents have the disadvantage that the applications need to be aware of the pool and need to be specifically designed be compatible with data pool servers. A further problem arises with the above mentioned state of the art documents. In certain cases, such as a SAP application server, database connections must be reserved prior to use. This is necessary to reduce deadlocks due to other activity of the application server.